A partir del trabajo realizado se han identificado una serie de necesidades y posibles mejoras de la herramienta. Se presenta a continuación una clasificación basada en la prioridad de las mismas.

\begin{itemize}
\item \emph{Agregados}

El uso de agregados en bases de datos está ampliamente extendido (sentencias \cod{GROUP BY}, \cod{HAVING}). A diferencia de otras sentencias SQL que pueden ser traducidas a otras equivalentes que nuestra herramienta ya soporta (apéndice \ref{app:ejemploEqivalencia}), los agregados necesitan un trato diferenciado. El uso de agregados está contemplado en \cite{flops2010}, y la inclusión en nuestra herramienta no debería suponer grandes complicaciones. Sin embargo, y aún considerando necesaria esta característica para poder considerar completa la herramienta, la versión actual del prototipo no admite todavía este tipo de sentencias.

\item \emph{Tipos de datos}: 

Un gran número de bases de datos utiliza sólo datos de tipo entero o cadenas de caracteres. Actualmente la herramienta da soluciones sólo para tipos enteros, sin embargo está diseñada para trabajar con diferentes tipos de datos. Una de las mayores dificultades a la hora de admitir nuevos tipos de datos es la traducción a restricciones de sus funciones y condiciones específicas (por ejemplo los filtros mediante expresiones regulares o las concatenaciones en cadena de caracteres) y mantener la sintaxis de las condiciones más generales que afectan a varios tipos de datos (comparaciones, desigualdades, etc.). El trabajo de modelar como restricciones las condiciones sobre cadenas de caracteres está en gran parte implementado en un trabajo reciente \cite{mznStrings} por lo que la inclusión de esta característica no sería muy costosa.


\item \emph{Configuración del dominio de las variables}

El prototipo genera fórmulas sobre variables enteras sin restringir su dominio. Este comportamiento es el esperado, ya que no se puede conocer a priori un dominio para los valores enteros que sea válido para todas las bases de datos. Sin embargo, esto puede hacer que el tiempo usado para encontrar soluciones sea considerablemente más elevado que si el dominio de las variables fuera restringido. Parece razonable entonces ofrecer al usuario la configuración del dominio de las variables, acelerando el proceso de búsqueda de soluciones y dejando en manos del usuario la decisión de los valores válidos para su base de datos.

\item \emph{Valores nulos}

Los valores nulos (NULL) sirven para representar que un determinado dato no existe en la base de datos. En \cite{Tuya:2006} se muestra el enfoque a adoptar para tratar con valores nulos en white-box testing para SQL. Se debe usar la lógica ternaria (lógica con tres valores: Cierto, Falso y Desconocido) que utiliza SQL para tratar con datos nulos. Además, sería necesaria la introducción de una representación adecuada de los valores nulos en el modelo de restricciones. El uso de valores nulos es interesante, sin embargo su implementación no es tan simple como a priori pudiera parecer.

\item \emph{Integración con otras herramientas}

La herramienta sería de gran utilidad si pudiera integrarse con otras herramientas complementarias de depuración y prueba. Por ejemplo, en la herramienta presentada en \cite{Tuya:2010} que puede ejecutarse online en la siguiente dirección: http://in2test.lsi.uniovi.es/sqlfpc/SQLFpcWeb.aspx se subdivide una consulta en un conjunto de consultas que conforman un recubrimiento exhaustivo. La resolución de dichas consultas con nuestra herramienta supondría la obtención del conjunto de prueba para la consulta en cuestión.

\item \emph{Ampliación de la sintaxis admitida}

Actualmente el prototipo admite un subconjunto reducido del lenguaje SQL (ver sección \ref{sec:ambito} y apéndice \ref{app:grammar}). Ampliar el lenguaje admitido supondría una clara mejora de la herramienta, que podría utilizarse sin necesidad de reescritura en un mayor número de bases de datos. Es conocida la equivalencia entre algunas sentencias SQL y las sentencias admitidas por la herramienta (ver apéndice \ref{app:ejemploEqivalencia}). Así, podemos afrontar este objetivo desde dos perspectivas diferentes: transformar mediante un análisis previo estas sentencias en sentencias ya soportadas por la herramienta o incluirlas directamente en el parser del que dispone actualmente el prototipo. Algunas de las sentencias SQL que sería interesante que nuestra herramienta admitiera son: 
\begin{itemize}
\item \textbf{Subconsultas de tipo \cod{ANY}, \cod{IN}, \cod{ALL}}. A través de la conversión en subconsultas existenciales equivalentes.
\item \textbf{Subconsultas en la clausula \cod{FROM}}. Esto se puede conseguir mediante la transformación a vistas intermedias de dichas subconsultas.
\end{itemize}

\item \emph{Optimización de fórmulas generadas}

En la versión actual del prototipo, las fórmulas generadas no pasan por un proceso de optimización que las transforme en fórmulas más claras o más eficientes. Las fórmulas que actualmente generamos tienen muchas expresiones que podrían simplificarse como por ejemplo \cod{True OR X} se simplifica a \cod{X}, la transformación a fórmulas más simples facilitaría la comprensión del las mismas. Además, a través del estudio estadístico del tiempo de ejecución de formas equivalentes de expresar las restricciones podría guiarnos a una generación más eficiente de las mismas.


\item \emph{Expresividad de salida del parser}

Si bien el analizador sintáctico de la herramienta no pretende ser un compilador de SQL, sí debería dar una salida significativa de los motivos por los cuales rechaza cierta entrada, sobre todo si la misma está bien formada pero no está soportada actualmente por la versión actual del prototipo.

\item \emph{Ordenación de resultados de salida}

Se ha observado que, en ocasiones, la salida de texto que representa el caso de prueba obtenido por el prototipo, al introducirse directamente en la base de datos como código SQL, no instancia la base de datos con el caso de prueba completo. Esto es debido a las restricciones de las claves ajenas (FOREIGN KEY) y se puede solucionar cambiando el orden de introducción de las sentencias en la base de datos. Esto no debe entenderse como un error ya que la salida debe considerarse como una instancia de una base de datos independiente del orden de las mismas. La presentación como sentencias SQL se proporciona para dar claridad y facilitar la introducción de la salida en la base de datos. La resolución de este problema no es trivial para algunos casos (ciclos en las relaciones de clave ajena, por ejemplo), por lo que debe estudiarse si la solución debe venir de la herramienta o de la interacción del usuario con la base de datos.


\item \emph{Traducción a otros lenguajes de restricciones y resolutores}

El prototipo permite la traducción de las restricciones generadas a diferentes lenguajes de restricciones (ver sección \ref{sec:resolutor}). Actualmente solo se traduce a código MiniZinc \cite{MiniZinc}, pero sería interesante ampliar la variedad de lenguajes a las que la herramienta traduce las restricciones.

\end{itemize}